fix(react): extend the adapter-only data.* constant-predicate diagnostic to disabled / disabledOn - #6702

Fixes #6504

What

Extends objectui#5687's adapter-only data.* constant-predicate diagnostic to the
disabled / disabledOn gate — dev-only, per the 2026-08-27 maintainer ruling (Option A)
recorded on this issue.

reportAdapterOnlyDataPredicate names a predicate that evaluates perfectly, against the
wrong object: at the node tier data is the data-source adapter, not the row, so
data.status == 'locked' is a constant for every row. It was wired only into the
visibility chain's dev leg (evaluateVisibilityPredicate). A disabled predicate written
the same way faults nothing (#6445's fault reporter correctly stays silent), and on the
constant's other polarity (data.locked == null, !data.assignee, or an adapter answering
nothing) hands the gate a constant true that greys the control out on every row, in every
build, with nothing on the console. evaluateEnablementPredicate now reports it too, in
development only — option C (always-on) stays excluded, outside the #5687 precedent.

The copy, and why its direction differs from the visibility leg

The visibility leg's sentence — "a constant false hides the node on every row while
looking exactly like a gate that said no" — is about the wrong polarity for this gate and
would be a false statement here. The ruling named the direction explicitly: on disabled,
the dangerous constant is true. The new enablement entry in ADAPTER_ONLY_GATE_COPY
(packages/react/src/utils/visibilityDiagnostic.ts) reads:

...and on THIS gate the dangerous polarity is a constant true: the node renders
DISABLED - on screen, greyed out, refusing input - on every row, in every build, while
looking exactly like a gate that said no. No pixel says the predicate is a constant, so
this line is the only thing that will ever name it.

It is not a reuse of the visibility sentence — the two are pinned as distinct strings, and
one new group-4-style test in SchemaRenderer.disabledGateFaultDiagnostic.test.tsx asserts
the enablement line does not contain hides the and the visibility line does not contain
DISABLED.

Where the dissolution pointer lives, and its verbatim source

Both #5687's own docblock and the new binding-inheritance clause are carried forward:
unresolvedDataPaths's "why this discriminator" section already reads (verbatim, unchanged
by this PR): "a diagnostic on a card that dissolves when objectui#5330's deprecation
window closes." This PR appends a clause at that exact spot — "BOTH legs together, the
enablement one objectui#6504 added included" — and adds a new docblock on
ADAPTER_ONLY_GATE_COPY itself that quotes the 2026-08-27 ruling's binding clause verbatim
and names every symbol + both call sites (evaluateVisibilityPredicate and
evaluateEnablementPredicate in SchemaRenderer.tsx) a #5330-window teardown has to delete
in the same stroke. Neither leg is independently scheduled.

Per the stop condition: #5330's deprecation window is not closing near-term — measured,
not assumed. Its Phase 2 carrier (#5741, the stored-metadata survey that gates removal) is
still open, pm:awaiting-maintainer, unassigned, blocked on a live-tenant data channel no
seat currently has. Proceeding per the ruling.

Ablation — both legs predicted before running, mutation/restoration proven on disk

Leg 1 — the new leg must produce the diagnostic, with the correct copy (evaluateEnablementPredicate's new call site removed).
Predicted: every new group-6 test that asserts a report turns red; every silence/negative
control stays green. Observed: exactly as predicted — 8/8 red (the acceptance
criterion, the constant-true direction, the copy-is-not-reused assertion, the
cross-gate content check, disabledOn, the two dedupe cases, and the pre-existing test this
PR rewrote from a negative to a positive pin), 24/24 other cases (including every
false-positive/negative control) stayed green. Mutation confirmed on disk (call-site grep
count 1→0, blob hash changed); restore confirmed (git diff HEAD empty, hash back to
57c0beb3f…).

Leg 2 — false-positive direction (a genuinely row-dependent predicate must not fire it).
Mutated the shared discriminator regex (DATA_ROOT_PATH_RE, unchanged by this PR's actual
diff) to also treat record as a matched root, to probe whether the shared false-positive
protection this leg inherits (rather than reimplements) is real. Prediction missed, and
reported as observed rather than forced: I predicted the new FALSE-POSITIVE CONTROL
test (disabled: "record.status == 'open'") and nodeGateDataPredicate.test.tsx's 3a
would flip; neither did — both stay silent behind an independent guard
(source.indexOf('data.') === -1 fast-reject: neither predicate string contains the
literal substring data. at all, so the mutated regex is never reached). What did flip
were two pre-existing, unrelated pins in nodeGateDataPredicate.test.tsx — 2d
(a quoted 'data.status' literal) and 3d (record.data.status, whose . before data
the original regex's exclusion group is specifically built to reject) — both already-hardened
false-positive guards this card didn't write, doing their job against a hostile version of
code this card also didn't write. Net: this leg adds no new discriminator logic (no new
regex, no new resolution algorithm), only a second call into the existing, shared,
already-tested function with a gate label — so its false-positive resistance is by
construction identical to the visibility leg's, not a new surface to separately harden.
Mutation confirmed on disk (marker count 0→1, hash changed); restore confirmed (git diff HEAD empty, hash back to 40e466e7d…).

Leg 3 — the visibility leg is unchanged. evaluateVisibilityPredicate's call site
(line ~772 in SchemaRenderer.tsx) is untouched — no gate argument added, still defaults
to 'visibility'. SchemaRenderer.nodeGateDataPredicate.test.tsx (40 tests, the full
#5687/#5756 suite) and SchemaRenderer.concealmentGateFaultDiagnostic.test.tsx pass
unmodified, byte-identical to origin/main. Leg 1's mutation (which only touched the
enablement call site) independently confirms zero effect on any visibility-leg test.

Gate table

Lint narrowing justification (repo has no type-aware linting configured — no project /
projectService in eslint.config.js — so this diff cannot move any judgment on an
untouched file): file count is eslint's own --format json output (3), not a guess; the
config's rule set is untyped, so the invariance claim is structural, not assumed.

Union re-run: 20c52cedf (branch head, pushed) — the commit these results are quoted
against.

Fence

Touched only packages/react/src/utils/visibilityDiagnostic.ts,
packages/react/src/SchemaRenderer.tsx (the evaluateEnablementPredicate call site the
existing docblock there explicitly anticipated this card would fill in), and one test file.
Did not reach packages/types' exports map, app-shell, or plugin-designer — no
overlap with #6527's in-flight patch round.

No published type widened: AdapterOnlyPredicateGateKind and
ADAPTER_ONLY_ENABLEMENT_PREDICATE_PREFIX are module-internal exports (not re-exported from
packages/react/src/index.ts), matching #5687's own ADAPTER_ONLY_DATA_PREDICATE_PREFIX /
formatAdapterOnlyDataMessage / reportAdapterOnlyDataPredicate, none of which are on the
package's public barrel either. No runtime behaviour change outside __DEV__.

Generated by Claude Code